Today we are talking about Drupal 11 Readiness, What you need to think about, and PHPStan with guest Matt Glaman. We'll also cover MRN as our module of the week.

For show notes visit: [www.talkingDrupal.com/448https://www.talkingDrupal.com/448)

Topics

• What do we mean by Drupal 11 Readiness
• How will this be different than 9 and 10
• Top 5 tips
• D11 Meeting and slack channel
• Will this be easier
• Major issues
• What is PHPStan
• How does it play a role
• How is PHPStan Drupal different than PHPStan
• Does using PHPStan with drupal reduce the need for tests
• How do you see it evolving over the next few years
• Drupal 12 wishlist

Resources

• PHPStan Drupal
• PHPStan
• Herodevs DrupalCon Party
• Smart date BC calls
• Contrib semantic versioning thoughts
• Change records
  • Drop is always moving
• Project analysis
• Gabor article Drupal rector
• Project update working group
• LTS even odd
• PHP version
• PHP stan rule levels
• Title issue

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Matt Glaman - mglaman.dev mglaman

MOTW Correspondent

Martin Anderson-Clutz - mandclu

• Brief description:
  • Have you ever wanted an easy way to generate detailed release notes for your contrib projects? There's a web app for that
• Module name/project name:
  • MRN which is short for Maintainer / Module Release Notes
• Brief history
  • How old: created in Aug 2022 by today's guest Matt Glaman
• Maintainership
  • Actively maintained, latest updates were earlier this year
  • Code project at https://github.com/mglaman/drupal-mrn has 13 open issues
• Usage stats:
  • Currently no usage reporting, but a tool I've been using a ton lately as I get modules ready for Drupal 11
• Module features and usage
  • It's very simple to use, you just enter the machine name of your project, and then the numbers of the releases you want it to compare
  • It will generate the structure for your release note, include a spot for you to write a summary at the top, a list of contributors that links to their profiles, and a list of issues
  • Previously part of Matt's drupalorg CLI project, MRN is now a lambda function on AWS, so there's nothing to download or install
  • I like that you can choose which tags you want to compare, so if the release is part of a branch that doesn't yet have a stable release, I'll put a comparison to the previous release in the branch at the top, and then a comparison to the current stable release below it, so people can see the full list of everything new they'll get by moving from the stable release
  • It's worth noting that because this works from the git history, you need to make sure you credit everyone properly before clicking to merge an MR in the Drupal.org UI. You can give credit to other people after the fact using the checkbox and they'll get contribution credits, but won't be included in the release notes generated by MRN

29 Apr 2024 6:00pm GMT

Symfony 7.0.7 has just been released. Here is the list of the most important changes since 7.0.6: bug #54699 [DoctrineBridge] Update AbstractSchemaListener to adjust more database params (@ywisax) bug #54691 [Finder] Also consider .git inside the basedir…

29 Apr 2024 12:50pm GMT

Symfony 6.4.7 has just been released. Here is the list of the most important changes since 6.4.6: bug #54699 [DoctrineBridge] Update AbstractSchemaListener to adjust more database params (@ywisax) bug #54691 [Finder] Also consider .git inside the basedir…

29 Apr 2024 12:09pm GMT

SymfonyLive Berlin 2024 is just around the corner and will start on June 20-21. Get ready for the impressive lineup of speakers and topics. Visit here to more details and don't miss out on this exciting opportunity! We're excited to reveal the next…

29 Apr 2024 11:30am GMT

Getting Smart Date Dialed Up to 11

mandclu Mon, 04/29/2024 - 06:14

• Read more about Getting Smart Date Dialed Up to 11
• Add new comment

29 Apr 2024 10:14am GMT

The Impact of Web Design on Conversion: Strategies and Tools for a Successful Web Project

Editor Mon, 04/29/2024 - 13:01

29 Apr 2024 10:01am GMT

EDIT 2024-04-25: Clarified when a PHP application is vulnerable to this bug.Recently, a bug in glibc version 2.39 and older (CVE-2024-2961) was uncovered where a buffer overflow in character set conversions to the ISO-2022-CN-EXT character set can result in remote code execution. This specific buffer overflow in glibc is exploitable through PHP, which exposes the iconv functionality of glibc to do character set conversions via the iconv extension. Although the bug is exploitable in the context of the PHP Engine, the bug is not in PHP. It is also not directly exploitable remotely. The bug is exploitable, if and only if, the PHP application calls iconv functions or filters with user-supplied character sets. Applications are not vulnerable if: Glibc security updates from the distribution have been installedOr the iconv extension is not loadedOr the vulnerable character set has been removed from gconv-modules-extra.confOr the application passes only specifically allowed character sets to iconv. Moreover, when using a user-supplied character set, it is good practice for applications to accept only specific charsets that have been explicitly allowed by the application. One example of how this can be done is by using an allow-list and the array_search() function to check the encoding before passing it to iconv. For example: array_search($charset, $allowed_list, true) There are numerous reports online with titles like "Mitigating the iconv Vulnerability for PHP (CVE-2024-2961)" or "PHP Under Attack". These titles are misleading as this is not a bug in PHP itself. If your PHP application is vulnerable, we first recommend to check if your Linux distribution has already published patched variants of glibc. Debian, CentOS, and others, have already done so, and please upgrade as soon as possible. Once an update is available in glibc, updating that package on your Linux machine will be enough to alleviate the issue. You do not need to update PHP, as glibc is a dynamically linked library. If your Linux distribution has not published a patched version of glibc, there is no fix for this issue. However, there exists a workaround described in GLIBC Vulnerability on Servers Serving PHP which explains a way on how to remove the problematic character set from glibc. Perform this procedure for every gconv-modules-extra.conf file that is available on your system.Once an update is available in glibc, updating that package on your Linux machine will be enough to alleviate the issue. You do not need to update PHP, as glibc is a dynamically linked library.PHP users on Windows are not affected.There will therefore also not be a new version of PHP for this vulnerability.

24 Apr 2024 12:00am GMT

I'm a maintainer of several small open-source libraries. It's a fun activity. If the scope of the library is small enough, the maintenance burden is typically fairly low. They're usually mostly 'done', and I occasionally just need to answer a few questions per year, and do the occasional release to bring it back up to the current 'meta' of the ecosystem.

Also even though it's 'done', in use by a bunch of people and well tested, it's also good to do a release from time to time to not give the impression of abandonment.

This weekend I released a 2.0 version of my bigint-money library, which is a fast library for currency math.

I originally wrote this in 2018, so the big BC break was switching everything over to ESM. For a while I tried to support both CommonJS and ESM builds for my packages, but only a year after all that effort it frankly no longer feels needed. I was worried the ecosystem was going to split, but people stuck on (unsupported) versions of Node that don't support ESM aren't going to proactively keep their other dependencies updated, so CommonJS is for (and many others) in the past now. (yay!)

Probably the single best way to keep maintenance burden for packages low is to have few dependencies. Many of my packages have 0 dependencies.

Reducing devDependencies also helps. If you didn't know, node now has a built-in testrunner. I've been using Mocha + Chai for many many years. They were awesome and want to thank the maintainers, but node --test is pretty good now and has pretty output.

It also:

• Is much faster (about twice as fast with Typescript and code coverage reporting, but I suspect the difference will grow with larger code bases).
• Easier to configure (especially when you're also using Typescript. Just use tsx --test).
• It can output test coverage with (--experimental-test-coverage).

Furthermore, while node:assert doesn't have all features of Chai, it has the important ones (deep compare) and adds better Promise support.

All in all this reduced my node_modules directory from a surprising 159M to 97M, most of which is now Typescript and ESLint, and my total dependency count from 335 to 141 (almost all of which is ESLint).

Make sure that Node's test library, coverage and assertion library is right for you. It may not have all the features you expect, but I keep my testing setup relatively simple, so the switch was easy.

21 Apr 2024 3:00am GMT

Concealing Cacophony

Tuesday, April 16th 2024, 14:30 BST

London, UK

Over the last few weeks I have been publishing a series of videos on writing PHP extensions.

I record these videos through OBS, and then slice and dice them with Kdenlive. This editing is necessary to make up for my mistakes, shorten the time we wait for things to compile, and to remove the noise of me hammering away on my keyboard.

Editing takes a lot of time, and I still wasn't always pleased with the result as there was still a fair amount of noise while I am talking.

For the PHP Internals News podcast, I used a set of noise cancellation filters, which worked wonders. But it turns out that Kdenlive does not come with one built in.

I had a look around on the Internet, and learned that there is a LADSPA Noise Suppressor for Voice plugin. LADSPA is an open API for audio filters and audio signal processing effects. LADSPA plugins can be used with Kdenlive.

Some Linux distributions have a package for this LADSPA Noise Suppressor for Voice, but my Debian distribution bookworm does not.

I found instructions that explain how to build the plugin from source. These instructions worked after some tweaks. I ended up creating the following script:

#!/bin/bash

sudo apt install cmake ninja-build pkg-config libfreetype-dev libx11-dev libxrandr-dev libxcursor-dev
git clone https://github.com/werman/noise-suppression-for-voice /tmp/noise
cd /tmp/noise
cmake -Bbuild-x64 -H. -GNinja -DCMAKE_BUILD_TYPE=Release
sudo ninja -C build-x64 install

After running this script, and restarting Kdenlive, I found the installed plugin when I searched for it.

With the plugin loaded, I now have much clearer sound, and I also don't have to edit the sections where I am typing, as the plugin automatically handles this.

I will still have to edit out my mistakes.

I then also had a look at how it worked. It turns out that this plugin uses neural networks to cancel the noise.

In the background, it uses the RNNoise library which implements an algorithm by Jean-Marc Valin, as outlined in this paper. There is an easier to read version of how the algorithm works on his website.

The data to train the model is also freely available, and uses resources from the OpenSLR project. Noise data is also available there. From what I can tell, all this data was contributed under reasonable conditions, and not scraped from the internet without consent. That is important to me.

Hopefully, from the third video in the series, you will find the sound quality much better.

16 Apr 2024 1:30pm GMT